Business Analyst Community & Resources | Modern Analyst

What approach should a business analyst take when gathering requirements from high level executives versus the end users?

sonavi — Mon, 09 Aug 2021 13:30:00 GMT

For the most part, the methods and techniques for gathering requirements are the same regardless of whom the stakeholders are: interviews, focus groups, questionnaires, requirements workshops.

However, there are definite things that the business analyst should consider when gathering requirements from high-level executives vs. the end users. The business analyst should tailor his approach and expectations based on the stakeholder type.

In which document do you include the Class Diagram (business requirements, functional requirements, software specification document)?

sonavi — Mon, 12 Nov 2018 16:20:00 GMT

Just like any other diagram, the Class Diagram is just a tool at the disposal of the analyst. In the absence of a set process, it is at the analyst’s discretion to determine when to use a class diagram. Therefore, in which analysis artifact/document a class diagram should be included depends on its use.

What does a requirements document contain?

sonavi — Fri, 08 Feb 2008 01:17:00 GMT

Short Answer: Requirements! ;-)

Seriously... The reality is that there isn't such as thing as a standard requirements document template to help guide the business analyst in the creation of this document.

The format of a Requirements Document vary depending on the type and size of project, type of organization, maturity of the business analysis team, use of specialized requirements management tools, type of methodology and development process(agile vs. RUP vs. structured analysis), etc.

Having said that, here are some common types of information found in many requirements documents:

Background/History
Scope and Objectives
Regulatory Requirements
Business Level Requirements
- Strategic
- Tactical (Interoperability)
- Operational (Process related mostly)
Stakeholder and User Analysis
User Requirements (the abilities that the users need)
Functional Requirements
Non-functional Level User Requirements
Assumptions/Constraints
Risks and Dependencies
Solution Options
Business Glossary (the nouns and noun-verb phrases of the business)
Reference to Business Rules
Reference to Business Case/Vision
Use Case Models

One more observation: requirements documents are also known by a variety of names which, at times, mean the same thing and, other times, refer to totally different documents:

Requirements Document
Business Requirements Document (BRD)
Software Requirements Document
Software Requirements Specification (SRS)